Subject: APPN HPR Feedback

From: "John Pickens" <[email-masked]>
Date: 29 Nov 1993 16:32:04 U

Subject:                              Time:  3:34 PM
  OFFICE MEMO         APPN HPR Feedback                     Date:  11/29/93
Here are a few comments on the HPR document draft dated 
September 24, 1993.  I have more detailed feedback, but 
figured it would be better to give at least this level of 
feedback before the next draft went out.

I. Control point model

My strongest feedback regards the description of the APPN/HPR 
control point vs. RTP layering.  It took me a while to finally 
figure out that the actual implicit model was of the control 
point logic of APPN/HPR being shared between old APPN sessions 
and new HPR RTP sessions.  A reusable control point.  It would be 
much cleaner to describe a set of common control point services 
that could be used by other entities within the node, e.g. the 
RTP/ANR route calculation entity.  A protocol boundary could 
be defined within APPN/HPR (actually extensions to existing 
protocol boundaries in the APPN architecture book, or a service 
level interface see below).  Then, RTP could be characterized 
as using this protocol boundary in pseudo code (ok, pseudo pseudo 
code to simplify the writing).  As it is, APPN, HPR, Control Point, 
RTP, ANR, are all muddled together.

(Also, I have said previously that it would be good to generalize 
the notion of the APPN control point for usage by other node 
services, such as DLS or other vendor defined functions.)

II. RTP - SNA layering & Service Interface

My understanding previously was that RTP was essentially a 
separable protocol stack, that, other than requiring access to 
control point services for name registration and route calculation,  
was separable from APPN.  RTP need not even run SNA.   However, 
the writeup of RTP essentially is very intertwined with APPN/SNA.  
A couple of suggestions here.

First, create a separate document for RTP.

Second,  create a service interface description for RTP.  (Actually 
you need an architectural model, service interface, and protocol 
description.)  What are its logical interface verbs.  connect(), 
disconnect(), send(), receive(), and the verb parameters.  Also, perhaps 
create a service interface for the control point functions used by RTP, 
such as find-route(), ...  This formalism will force the separation of 
layering such that RTP and APPN can be separately described (and 
implemented).  It may also fix some inadvertant layering violations 
that have crept into the architecture. 

Third,  my understanding was that the fact that SNA BIND was carried 
in an RTP connection activation was incidental.  The discussion in 
7.2.2 implies that a BIND MUST be carried.  BIND is just data, right?  
A BIND is only carried if the RTP user is communicating to an HPR 
entity, right?  Modify the discussion to show a pure RTP connection 
setup.  Then have a section under HPR that discusses what data is 
placed into the RTP connection setup request by HPR.  Perhaps the 
service interface approach could be used as an alternative documentation 
method here also.  

Finally, the performance graphs, proofs, design considerations etc. 
are all interesting, but are out of place in the main body of a protocol 
specification.  Maybe an informative appendix or separate white paper.  

III. Link Sharing

After scratching my head for a while it finally became apparent that 
the data link was being shared by two logically independent protocol 
stacks - APPN and HPR - duh.  Couple comments.

First, the mapping of FID2 and NLPs to a common link is not well 
described at all.  A graphic or two is required showing what you 
really mean.  It is confusing that FID2 uses a connection oriented 
link scheme, and NLP uses connectionless, all on the same link.  

Second, what are the rules for sharing the link?  For each NLP sent, 
how many FID2 PIUs should be sent?  Does session priority influence 
the relative traffic flows of each type?  

Finally, the bullet in 4.1 beginning "FID2 PIUs and NLPs share link" 
seems flawed.  How do you delineate the beginning and end of FID2 
and NLP structures?  None of the example mappings use the first 
3-4 bits to differentiate structure types anyway.

IV. Miscellaneous Comments

No particular order.

In a number of places there are imprecise handwaving implementation 
guidelines.  For example section 7.2.4.5 session adaptive pacing.  Is 
there any way to tighten up the specification, precise algorithms?  
I'm concerned about how well the implementations will work with 
this imprecision.

The whole discussion of limited resource links needs to be expanded 
and clarified.  

Need to define subnet types, CNN, HPR, APPN, ....

3.1.5 - is the "minor modification for path switch" to base APPN 
contained in this document?  Is enough information described to 
enable an implementor to do it correctly?

6.3.2 - new SAP for NLP - are you dedicating a well known SAP 
for this purpose?  SAPs are rare.  If it is a single SAP then it will 
break multiple SAP implemetations, like SDLC-to-LLC2.  Are you 
going to allow SNAP SAP?

7.2.3 - define dally, LMI, RASAPI, ...

7.2.4.1 and elsewhere - change all references to "customer" to 
something else like "administrator".  Protocol specs are for engineers, 
not sales folks.

7.2.4.4.7 - "this is the current design direction" - Let's pin it down.

7.2.4.5 Session Adaptive Pacing - is it legal to have a concatenated 
HPR-to-APPN-to-HPR configuration?  Also, need to specify more 
precisely what it means for "window size to be immediately or 
quickly be incremented".

7.9 Session addressing - a graphic showing the layered/fan-out 
relationship between SAD->TCID->NCE->Node would certainly be 
helpful.     

9.3 Connection Networks - this section needs to be rewritted for 
clarification.  It is confusing.  Also would be helped with graphics.  

9.6.2 and elsewhere -"architecture strongly recommends" - wrong 
audience.  The "specification" recommends.

9.6.10 - Obtaining a New Path - conditions checked - indicate that 
these are "AND" logic.  Also, it is not clear what you mean by 
"subnet" (comment earlier made).  

A.2.7 - TG Type  - what do each of the types actually mean?

That's all for now...